Full-stack delete is well done. CRUD, API, CLI, and both UI surfaces (dashboard and Danger Zone) are all covered. The FTS cleanup before CASCADE delete is the right order.

Two issues I found in the code:

1. CLI argument parsing bug (delete_cmd.py): There are two positional optional arguments, repo_id and path. Click assigns positional args left-to-right, so repowise delete /path/to/repo would assign the path string to repo_id, then fail when trying to look it up as a UUID. The path argument is effectively unreachable. Suggest making path an option (--path) instead of a positional argument.

2. FTS skip when None (repos.py): In delete_repo, FTS cleanup is skipped when fts is None. If FTS was not initialized on a cold start, old FTS rows would linger. Is this a real scenario? If FTS is always initialized before any delete could happen, a comment explaining that would help future readers.

Logic and tests otherwise look solid. Fix the CLI argument issue and this is ready to merge.

Took another look at this. The FTS comment addresses my concern, and re-reading the CLI args I see path is already a --option not positional, so that's fine.

Just needs a rebase on main since there are conflicts now. Once that's resolved I'll merge.

rebased

Rebased on main and addressed both points from the latest review:

1. Settings page redirect (swati510 Bump next-mdx-remote from 5.0.0 to 6.0.0 #1): Added an optional redirectTo prop on DeleteRepoButton. The dashboard still uses router.refresh(); the settings page now passes redirectTo="/" so it router.push("/") after the repo is gone instead of re-rendering a 404 route.
2. FTS delete_many perf (swati510 Bump next from 15.5.13 to 15.5.14 #2): Replaced the per-id loop with a single DELETE FROM page_fts WHERE page_id IN (...) per 500-id chunk inside the existing transaction. Chunked to stay under SQLite's 999-parameter limit.